Database management system with coding cluster and methods for use therewith

ABSTRACT

A networked database management system (DBMS) is disclosed. In particular, the disclosed DBMS includes a plurality of nodes, one of which is elected as a designated leader. The designated leader is elected using a consensus algorithm, such as tabulated random votes, RAFT or PAXOS. The designated leader is responsible for managing open coding lines, and determining when to close an open coding line.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present U.S. Utility Patent Application claims priority pursuant to35 U.S.C. § 120 as a continuation of U.S. Utility application Ser. No.17/659,203, entitled “DATABASE SYSTEM WITH DESIGNATED LEADER AND METHODSFOR USE THEREWITH”, filed Apr. 14, 2022, which is a continuation of U.S.Utility application Ser. No. 17/092,567, entitled “DATABASE MANAGEMENTSYSTEM AND METHODS FOR USE THEREWITH”, filed Nov. 9, 2020, issued asU.S. Pat. No. 11,334,257 on May 17, 2022, which is a continuation ofU.S. Utility application Ser. No. 15/840,633, entitled “SYSTEM ANDMETHOD FOR DESIGNATING A LEADER USING A CONSENSUS PROTOCOL WITHIN ADATABASE MANAGEMENT SYSTEM”, filed Dec. 13, 2017, issued as U.S. Pat.No. 10,868,863 on Dec. 15, 2020, which claims priority pursuant to 35U.S.C. § 119(e) to U.S. Provisional Application No. 62/433,919, entitled“USE OF A DESIGNATED LEADER TO MANAGE A CLUSTER OF NODES IN AN DATABASEMANAGEMENT SYSTEM”, filed Dec. 14, 2016, all of which are herebyincorporated herein by reference in their entirety and made part of thepresent U.S. Utility Patent Application for all purposes.

This application is also related to U.S. Patent Application No.62/403,231, entitled “HIGHLY PARALLEL DATABASE MANAGEMENT SYSTEM,” filedon Oct. 3, 2016 in the name of George Kondiles, Rhett Colin Starr,Joseph Jablonski, and S. Christopher Gladwin, and assigned to OcientInc., and which is hereby included herein in its entirety by reference.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to networked databasemanagement systems (DBMS) and supporting infrastructure. Moreparticularly, the present disclosure relates to computer softwareapplication access to resources, such as memory and disk. Moreparticularly still, the present disclosure relates to a system andmethod by which a database application maintains open lines, and moreparticularly still, the present disclosure relates to a system andmethod by which a governing node, referred to as a designated leader,can be elected using consensus protocol.

BACKGROUND

A DBMS is a suite of computer programs that are designed to manage adatabase, which is a large set of structured data. In particular, a DBMSis designed to quickly access and analyze data on large amounts ofstored data. Most modern DBMS systems comprise multiple computers(nodes). The nodes generally communicate via a network, which will use anetwork protocol, such as HTTP, or raw TCP/IP. Information that isexchanged between nodes is exchanged by packets, the specific format ofwhich will be determined by the specific protocol used by the network.The data wrapped in the packet will generally be compressed to thegreatest extent possible to preserve network bandwidth. Accordingly,when it has been received, it will have to be formatted for use by thereceiving node. A variety of DBMSs and the underlying infrastructure tosupport them are well known in the art. Database input/output (“I/O”)systems comprise processes and threads that identify, read, and writeblocks of data from storage; e.g., spinning magnetic disk drives,network storage, FLASH drives, or cloud storage.

Like many software systems, DBMS evolved from standalone computers, tosophisticated client/server setups, to cloud systems. An example of acloud based DBMS is depicted in FIG. 1 . In particular, a cloud system 2will generally comprise a variety of nodes (computers) as well assoftware that operates on the nodes. The cloud system 2 will comprisenumerous separate nodes, including multiple database servers 1. Eachdatabase server will maintain separate storage (not depicted), whichwill store some part of the maintained data. Various clients can accessthe cloud system 2 through the Internet 4. Clients can include, forexample, a standard desktop or laptop computer 6, a mobile device 7, aswell as various sensors 8 and control equipment 9.

Generally, DBMSs operate on computer systems (whether standalone,client/server, or cloud) that incorporate operating systems. Operatingsystems, which are usually designed to work across a wide variety ofhardware, utilize device drivers to abstract the particular functions ofhardware components, such as, for example, disk controllers, and networkinterface cards. As drivers are generally accessed through an operatingsystem, such accesses will typically entail significant resourceoverhead such as a mode switch; i.e., a switch from executingapplication logic to operating system logic, or a context switch; i.e.,the pausing of one task to perform another. Such switches are typicallytime consuming; sometimes on the order of milliseconds of processortime.

Data stored in a DBMS is usually stored redundantly, using, for example,a RAID controller, Storage Area Network (“SAN”) system, or disperseddata storage. For example, using prior art RAID techniques, data may besplit into blocks and to ensure that data is recovered; and one or morenodes within a coding line can maintain parity. For example, for asixteen node system, twelve nodes may store data blocks, while fournodes would store parity blocks. Other data/parity configurations, suchas thirteen and three, or ten and six, could be used, and parity can bedetermined using any of the well-known prior art techniques.

A DBMS system must maintain a record of storage that has not yet beenutilized. Slow speed databases can make use of the operating system tomanage open storage. However, high speed databases need to maintaintheir own list of open storage. In addition, such databases need toutilize a method to determine when to recycle storage that had been inuse, but is no longer in use.

A fundamental problem in distributed computing and multi-agent systemsis to achieve overall system reliability in the presence of a number offaulty processes. This often requires processes to agree on some datavalue that is needed during computation. Examples of applications ofconsensus include whether to commit a transaction to a database, oragreeing on the identity of a leader. There are a number of such methodsof agreement that are well known in the prior art.

OBJECTS OF THE DISCLOSED SYSTEM, METHOD, AND APPARATUS

Accordingly, it is an object of this disclosure to provide a new andimproved system and method for maintaining a list of open coding lineswithin a DBMS;

Another object of the disclosure is to provide an improved DBMS thatutilizes a designated leader to manage a list of open coding lines;

Another object of the disclosure is to provide an improved DBMS thatutilizes a parity pattern assigned by a designated leader to manageparity nodes;

Another object of the disclosure is to provide an improved DBMS thatutilizes a designated leader to modify the parity pattern on a codingline to coding line basis;

Other advantages of this disclosure will be clear to a person ofordinary skill in the art. It should be understood, however, that asystem or method could practice the disclosure while not achieving allof the enumerated advantages, and that the protected disclosure isdefined by the claims.

SUMMARY OF THE DISCLOSURE

A networked database management system along with the supportinginfrastructure is disclosed. The disclosed DBMS comprises a plurality ofnodes, one of which is elected as a designated leader using a consensusalgorithm. Under various circumstances, a new election of a designatedleader takes place. For example, on system startup or when the previousdesignated leader experiences a verified failure. In addition, thedesignated leader is responsible for managing open coding lines; i.e.,coding lines that have not been completely filled with data. Thedesignated leader determines when a coding line is to be closed; i.e.,it cannot hold more data, and should be flushed to disk if needed; NVRAMsystems will not require this step.

In particular, a database management system comprising three or morenodes is disclosed. Each of the nodes comprises a network interface toallow the node to communicate with other nodes, and other devices, suchas administration consoles. A high-speed switch is coupled to thenetwork interface of each of the nodes, and allows the nodes tocommunicate with one another (and other devices). There are variouscircumstances wherein the nodes will utilize a consensus algorithm toelect a designated leader. On startup, all of the nodes will participateto elect a designated leader. Similarly, when a majority of nodes losecontact with the designated leader, the nodes that are not thedesignated leader cooperate to elect a new designated leader. Inaddition, when there is a verified failure of the designated leader, thenodes that are not the designated leader cooperate to elect a newdesignated leader. In all cases, the electing nodes utilize a consensusprotocol such as RAFT or PAXOS (although in the case of RAFT, theelection of the leader is actually part of the protocol).

BRIEF DESCRIPTION OF THE DRAWINGS

Although the characteristic features of this disclosure will beparticularly pointed out in the claims, the invention itself, and themanner in which it may be made and used, may be better understood byreferring to the following description taken in connection with theaccompanying drawings forming a part hereof, wherein like referencenumerals refer to like parts throughout the several views and in which:

FIG. 1 depicts a prior art simplified network diagram of a cloud basedDBMS system.

FIG. 2 is a simplified block diagram illustrating a database system inaccordance with this disclosure.

FIG. 3 is a simplified block diagram illustrating a high-performancedatabase system constructed in accordance with this disclosure.

FIG. 4 is a simplified block diagram illustrating a segment groupconstructed in accordance with this disclosure.

FIG. 5 is a simplified flowchart illustrating a process for electing adesignated leader in accordance with this disclosure.

FIG. 6 is a table listing representative events that can cause a newelection for a designated leader to be determined in accordance withthis disclosure.

FIG. 7 is a simplified flowchart illustrating how data is stored in acoding block in accordance with this disclosure.

FIG. 8 is a simplified flowchart illustrating how nodes, the designatedleader, and parity peers cooperate to store data in accordance with thisdisclosure.

FIG. 9 is a simplified block diagram illustrating a representativeparity rotation pattern for a database system constructed in accordancewith this disclosure.

FIG. 10 is a simplified block diagram illustrating a representativeparity rotation pattern for a database system constructed in accordancewith this disclosure.

FIG. 11 is a simplified block diagram illustrating a representativeparity rotation pattern for a database system constructed in accordancewith this disclosure.

FIG. 12 is a representative data structure for holding an exception listas constructed in accordance with this disclosure.

FIG. 13 is a simplified flow chart illustrating a process by which anentry in an exception table can be created in accordance with thisdisclosure.

FIG. 14 is a simplified flow chart illustrating a process by which anexception table is cleared when a segment group is transitioned from onestorage temperature to another in accordance with this disclosure.

FIG. 15 is a simplified flow chart illustrating a process by which adesignated leader selects a node to aggregate data for a cluster ortable.

FIG. 16 is a simplified flow chart illustrating a process by which adesigned leader determines a number of nodes to select to aggregatedata.

A person of ordinary skills in the art will appreciate that elements ofthe figures above are illustrated for simplicity and clarity, and arenot necessarily drawn to scale. The dimensions of some elements in thefigures may have been exaggerated relative to other elements to helpunderstanding of the present teachings. Furthermore, a particular orderin which certain elements, parts, components, modules, steps, actions,events and/or processes are described or illustrated may not be actuallyrequired. A person of ordinary skill in the art will appreciate that,for the purpose of simplicity and clarity of illustration, some commonlyknown and well-understood elements that are useful and/or necessary in acommercially feasible embodiment may not be depicted in order to providea clear view of various embodiments in accordance with the presentteachings.

DETAILED DESCRIPTION

Turning to the Figures, and to FIG. 2 in particular a simplified blockdiagram illustrating the database system 112 is shown. The databasesystem 112 includes a payload store 202 for storing and serving data andan index store 204 for storing and managing indexes for accessing thedata stored payload store 202. The payload store 202 includes a set ofcoding clusters 206, 208 and 210 for storing data and serving data tocomputer software applications, such as applications running on clientcomputers.

Each coding cluster includes a number of nodes, such as the nodes 232and 234. In one implementation, the coding clusters each have the samenumber of nodes. For example, the number of nodes is five (5) in eachcluster. Each node includes one or more storage devices, such asNon-Volatile Memory Express (NVME) and Serial Advanced TechnologyAttachment (SATA) storage devices. Nodes within a coding cluster areconnected through high speed links. In other words, each cluster haslocal high-speed-interconnect (HSI), such as Infiniband, via a switch.The clusters are connected to each other through a switch 220 via highspeed links, such as the links 222 and 224. The links between theclusters are high-speed-interconnects, such as Infiniband or iWarp.

Referring now to FIG. 3 , an illustrative embodiment of thehigh-performance database system 112 is shown. Three coding clusters ofa payload store are indicated at 305, 315 and 325 respectively. A codingcluster of the index store 204 is indicated at 335. In the illustrativedatabase system 112, the clusters 305, 315 and 325 each include exactlyfive nodes indicated at 301, 311 and 321 respectively in theillustrative embodiment. The cluster 305 is a blazing storage cluster;the cluster 315 is a hot storage cluster; and the cluster 325 is a warmstorage cluster. In a further implementation, the database systemincludes or communicates with a cold cluster 345. As used herein,blazing, hot, warn and cold indicate data temperature that correspondsto the expected access rate of the data. For example, the age of thedata measured in days in a system where newer data is expected to beaccessed more frequently. For instance, blazing indicates that data isless than X days old, hot indicates that data is less than Y days oldand older than data in blazing clusters, warm indicates that data isless than Z days old and older than data in hot clusters, and coldindicates that data is at least Z days old. Z is bigger than Y while Yis bigger than X. For example, X is seven; Y is twenty-one; and Z isforty-two.

The links 308 and 309 are capable of remote direct memory access (RDMA).In particular, the index cluster 335 is connected to the storageclusters 305, 315, 325 by high speed, RDMA capable links 308. On theother hand, the storage clusters 305, 315, 325 are connected to oneanother by standard (non-RDMA capable) high performance network links309, such as 100Gbps Ethernet. Nodes within a cluster are linked usingHSI 308, such as Infiniband or iWarp Ethernet. Switches 303, 313, 323and 333 interconnect the clusters 305, 315, 325 and 335 over HSI 309 andHIS 308, such as 100 GB Ethernet. As discussed above, Infiniband, iWARPEthernet, RoCE Ethernet and Omnipath are examples of high speed, RDMAcapable links. Importantly, such links allow different nodes in eachcluster to exchange information rapidly; as discussed above, informationfrom one node is inserted into the memory of another node withoutconsuming processor cycles on either node.

The blazing storage node 305 may include, for example, an array ofNon-Volatile Dual Inline Memory Module (NVDIMM) storage, such as thatmarketed by Hewlett Packard Enterprise, or any other extremely faststorage, along with appropriate controllers to allow for full speedaccess to such storage. In one implementation, the storage is ApachePass NVRAM storage. The hot storage node 313 may include, for example,one or more Solid State NVME drives, along with appropriate controllersto allow for full speed access to such storage. The warm storage node323 may include, for example, one or more Solid State SATA drives, alongwith appropriate controllers to allow for full speed access to suchstorage.

Each index node 331 will also include storage, which will generallycomprise high performance storage such as Solid State SATA drives orhigher performance storage devices. Generally, the index nodes 331 willstore the database structure itself, which may comprise, for example, acollection of indexes and other data for locating a particular piece ofdata on a storage drive in a node within the payload store.

The blazing storage cluster 305 also comprises a high-speed switch 303.Each blazing storage node 301 is operatively coupled to the high-speedswitch 303 through a high speed, RDMA capable link 308. Similarly, eachhot storage node 311 is coupled to a high-speed switch 313 through ahigh speed, RDMA capable, link 308, and each warm storage node 321 iscoupled to the high-speed switch 323 through a high speed, RDMA capable,link 308. Similarly, the high-speed switches 303, 313, 323 are coupledto each storage cluster 305, 315, 325 are each coupled to the high-speedswitch 333 of the index cluster 335 by a high speed, RDMA capable, link308.

Turning to FIG. 4 , a collection of open coding lines is depicted. Fromleft to right, a number of segments 402, 404, 406, 408, 410, 412, 414,and 416 are depicted. As depicted, each segment 402 [ . . . ] 416 isstored on a separate node, although a node can hold multiple segmentsdepending on disk allocation; nonetheless, for purposes of thisapplication, only a single segment from a given node is represented in acoding line. From top to bottom, a number of coding lines 420, 421, 422,423, 424, 425, 426, 427, 428, 429, 430, 431, 432, 433, 499 are depicted.Each coding line comprises a collection of related data. As depicted,each coding line comprises (from left to right) a number of codingblocks 440A, 441A, 442A, 443A, 444A, 445A, 446A, 447A, each of whichholds related data. Strictly for purposes of illustration, a codingblock can be, for example, 4 kilobytes (KB) or 8 KB, which are typicalpage sizes of non-volatile FLASH memory, while a segment can be, forexample, 1 terabyte (TB), which is a typical size of a solid-statedrive. The sizes of a coding block and of a segment can, of course, bearbitrary, and are not limitations of this disclosure.

An open coding line is a coding line where at least one segment has atleast one open coding block. A DBMS must maintain at least one opencoding line at all times to accommodate various transactions, such asstorage transactions. More advantageously, the DBMS will strive tomaintain a minimum number of open coding lines so that every node in thecluster (and accordingly each segment) maintains at least one opencoding block. However, meeting such a goal requires coordination betweenthe nodes or a controlling entity. The latter solution is simpler, butcreates an additional problem; namely, if the controlling entity goesoff line, how are its responsibilities transitioned to another entity?

The disclosed system solves this problem by utilizing a designatedleader that is elected by a consensus protocol. In particular, the nodescooperatively determine which among their members shall act as thedesignated leader for that particular cluster. Once the designatedleader is determined, it is responsible for ensuring, among otherthings, that at least one coding block on each node is open so that aminimum number of open lines can be maintained.

There are numerous potential algorithms that the nodes within a clustercan utilize to determine a designated leader, any of which can be used.For purposes of education, however, one simple consensus algorithm thatcould be used would be for each node to randomly vote for any node inthe cluster, exchange those votes, and for the node with the most votesto be elected designated leader. In the case of ties, a revote istriggered. A simplified flowchart illustrating this process as executedby a node is depicted in FIG. 5 . Other well-known consensus protocols,such as RAFT and PAXOS could be used as well.

In a first step 502, an event triggers the selection of a new designatedleader. A listing of such events is depicted in the table of FIG. 6 . Instep 504, the node randomly selects any node (including itself) as itsvote for a designated leader. In step 506, the node transmits its voteto all other nodes in the cluster. In step 508, the node receives votesfrom other nodes in the cluster. In step 510, the node tabulates thevotes from all nodes, including itself. In step 512, the node determinesif the vote is a tie. If so, the process returns to step 504. Otherwise,the process has determined the designated leader, which is selected instep 514. The process of FIG. 5 is executed by all nodes in the cluster.

Table 6 lists a number of events by which a new designated leader willbe elected. In particular, these events include 1) system startup, 2) averified failure of the present designated leader, and 3) a loss ofconnectivity with a majority of nodes in the cluster. These events aremerely representative, and unless claimed, are not intended aslimitations of the disclosed DBMS.

Generally, the designated leader does not interfere with the insert(storage) process. In particular, when a client wishes to store a blockof data, it uploads the data to the DBMS. A cluster then receives thedata for writing on to a disk drive. In one implementation, a datadistributor (such as the computer 398 of the cluster 305) distributesthe block of data to a node within the cluster. The distribution israndom such that data is evenly distributed between nodes within thecluster. The node receiving the data inserts the data into one or moreopen coding blocks. The node then copies the newly inserted data to allnodes that store parity for the coding line. If, at the time that theclient seeks to store data there are no open coding lines, the node thatthe client reached out to will request that the designated leader open anew coding line. The designated leader will then open a predeterminednumber of coding lines, and the data will be stored as outlined herein.

A flowchart illustrating this process is depicted in FIG. 7 . In step701, a client contacts the DBMS with data to store. In step 702, adistributor within the DBMS contacts a node within a DBMS' cluster andtransmits the data to store to it. In step 704, the node checks whetherthere are any open coding lines. If there is not, in step 706 the noderequests that the designated leader open additional coding lines. Aftereither step 704 (if there is an open coding line) or after step 706(after the designated leader opens a coding line) the node then storesthe coding block. In step 708, the node then transmits the inserted datato all parity nodes for the coding line that the data is stored in.

The designated leader also tracks when a coding line is to be closed. Inparticular, each node will notify the designated leader when it hascompleted filling in a data coding block. After notifying the designatedleader the node then flushes the coding block from memory to disk. Thedesignated leader then notifies the parity peers for the coding line.The parity peers then 1) compute parity, 2) store the computed parity todisk, and 3) purge their copy of any coding blocks that they computedparity for.

A flowchart illustrating this process is depicted in FIG. 8 . In step802, a node notifies the designated leader that a particular codingblock is completely full. The node then flushes the coding block to disk(if necessary) in step 804—it should be noted that in certain NVRAMembodiments, there is no need to flush to disk. Transitioning to thedesignated leader, after being notified by a node that a particularcoding block is entirely full, the designated leader checks if allcoding blocks in a coding line are full in step 806. If all codingblocks in a coding line are not full, the designated leader leaves thecoding line open in step 808. However, if all coding blocks in a codingline are full, the designated leader retires the coding line in step810. Then, in step 812, the designated leader directs the parity peersfor the coding line to compute parity. In step 814, each parity peerthen computes parity, which is flushed to disk (if necessary) in step816. In step 818, each parity peer then purges its in-memory copies ofthe coding blocks for which it computed parity.

One advantage of this approach is that it allows for disk writes to bemade sequentially; i.e., blocks with sequential addresses can be writtentogether. For example, coding blocks, which can be sized to be the sameas a FLASH page, within a FLASH memory block can be writtensimultaneously so that only a single erase and write are required. Thisimproves FLASH memory durability substantially.

In addition, by allowing the designated leader to manage open lines,storage across nodes, as well as work load across nodes, can bebalanced. For example, when a line is retired, all nodes will store atleast one coding block. This also serves to minimize writeamplification, as writes are done only as required.

In addition, another aspect of this disclosure defines a method by whicha designated leader can manage the assignment of parity peers to opencoding lines. In particular, the designated leader serves to distributeparity peer responsibility across all nodes in a cluster so that certainnodes are not exclusively responsible for parity while other nodes areresponsible only for storing data. This improves the overall reliabilityand robustness of the DBMS.

In particular, the designated leader will decide on a parity pattern forthe cluster. As described earlier, parity peers are logically adjacentin the coding lines, and the order of all nodes in coding lines isidentical across all coding lines managed by a designated leader. Thedesignated leader rotates parity across all nodes on a fixed basis. Inparticular, as a collection of coding lines is traversed, one paritypeer is shifted to the right or left by a fixed number of nodes.

Parity rotation as discussed above with a rotation constant of 1 isillustrated in FIG. 9 . Horizontally, seven nodes are depicted and arelabeled as 902, 904, 906, 908, 910, 912, and 914. A total of six codinglines arranged vertically are labeled as CL0-CL5 and designated 920,921, 922, 923, 924, and 925. As depicted, each coding line includes fivedata nodes and two parity peers, with the data nodes being depictedwithout hatching, and the parity peers being depicted with hatching. Asdepicted, as the coding lines are traversed downwards from CL0, parityshifts one position to the right. For example, for CL0, nodes 912 and914 are designated as parity peers. For CL1, parity shifts one positionto the right, so nodes 914 and 902 are designated as parity peers. ForCL2, nodes 902 and 904 are designated as parity peers. The same patterncontinues for CL3-CL5. In such a case, the parity rotation is said tohave a rotation constant of 1.

FIG. 10 depicts parity rotation with a rotation constant of 2. Inparticular, seven nodes are depicted and labeled as 1002, 1004, 1006,1008, 1010, 1012, and 1014. A total of six coding lines arrangedvertically are labeled as CL0-CL5 and designated 1020, 1021, 1022, 1023,1024, and 1025. As depicted, each coding line again includes five datanodes and two parity peers, with parity peers again being demarcatedwith hatching. Again, parity shifts as the coding lines are traversedvertically. In particular, CL0 has two nodes serving as parity peers,1012 and 1014, and CL1 has the same parity peers. However, the paritypeers shift one to the right for CL2, which has designated as paritypeers nodes 1014 and 1002. Again, CL3 has the same parity peers as thepreceding line (CL2). For CL4 and CL5, nodes 1002 and 1004 function asparity peers; i.e., the parity peers shift one to the right for everytwo nodes.

Any integer rotation constant can be used; i.e., for a rotation constantof 3, the parity peers will change every three lines. In addition, whileparity is depicted as rotating to the right, it can rotate to the leftjust as easily, as depicted in FIG. 11 for a rotation constant of 2. Inaddition, other rotations could be used as well as long as the rotationis deterministic. For example, a pseudo-random number generationfunction could be used to generate a deterministic parity rotation forthis purpose.

The designated leader determines the parity rotation pattern for thecluster. If there are no exceptions (as discussed below), a particularblock can be located with the following information:

A) The parity pattern (i.e., whether parity nodes are stored onlogically adjacent nodes, whether they are separated by one, etc.);

B) The coding line offset;

C) The IDA offset;

D) The parity rotation constant; and

E) The number of data and parity nodes.

However, given real world circumstances, nodes can be expected to failfor a variety of reasons, ranging from a temporary loss of networkconnectivity to a complete system failure. When a node fails, the dataor parity that it stores needs to be reassigned to a different node.

The disclosed DBMS resolves this issue with an exception list, which mayalso be referred to herein as an exception table. In particular, when anode is not able to perform its function to store either data or parityfor a particular coding line, an exception is generated and stored inthe exception list. An example of an exception list is shown in FIG. 12. In a separate embodiment, an exception is only generated if a nodestoring data becomes non-functional.

In particular, an exception table can include an arbitrary number ofentries, each of which will include a starting coding line, an endingcoding line, and an updated parity pattern. The starting coding linestores the first coding line on which there is at least one down node.The ending coding line stores the last coding line in a range of codinglines on which there is at least one down node. A range of representedcoding lines can be any non-zero whole number of coding lines; i.e.; oneor greater. The parity pattern stores the parity pattern for theaffected lines; i.e., for the affected lines, the nodes in the affectedlines which store parity in view of the affected node(s). As depicted,the starting and ending coding line will occupy 16 bytes, while theupdated parity pattern, assuming a seven-node system with two paritypeers and five data nodes, will utilize two bytes.

The process of creating an entry in the exception table is illustratedin FIG. 13 . In particular, in step 1302, a node in the cluster noticesthat a node is not accessible. In step 1304, the node notifies thedesignated leader of the down node. In step 1306, the designated leadermodifies the parity pattern for all open coding lines including theinaccessible node and stores the updated parity pattern for the affectedcoding lines in its exception table. The designated leader then sends anupdate to the exception table to other nodes in step 1308. If new codinglines are opened prior to the inaccessible node being returned toservice, the new coding lines are also given the new parity pattern. Theupdate sent in step 1308 will modify the role of a previous parity nodeto become a data node. In step 1322, the new data node assumes its role;as all data to be stored in the line would have already been transmittedto the node in its previous role as a parity node, it can seamlesslyassume its role as a data node storing the data assigned to it by theparity pattern; i.e., the data assigned to the newly designated storagenode will already be stored in the node's memory. Note, the datadesignated to the parity node will generally not be flushed topersistent storage until the line is closed, unless the underlyingstorage is an NVRAM embodiment, in which case, no express storage topersistent storage would be required. As explained more thoroughly inapplication No. 62/403,231, which was previously incorporated byreference into this application, data can transition between storagetemperatures. In particular, a segment group can be copied from, forexample, blazing storage, to, for example, hot storage, where a segmentgroup is a number of related segments, such as a collection of driveswithin a cluster, with each drive residing on a different node. It isadvantageous to clear the exception list when data is transferred.

Clearing the exception list is easily done during the process of copyingthe data from one storage temperature to another storage temperate. Whena particular block is transitioned between storage temperatures, theoriginal (non-excepted) parity pattern is restored. As all nodes areaware of the default parity pattern, and the exception list, this isaccomplished by the node that holds data, which, without the exception,would be stored on a different node, transmitting the affected data tothe node designated by the default parity pattern when the datatransitions between storage temperatures.

This process is illustrated in FIG. 14 . In step 1402, a temperaturetransition is triggered for a particular segment group. Once a segmentgroup is scheduled for transition, the following process is repeated forevery coding block of every segment within the segment group. In step1404, a node storing a coding block consults the default parity patternand the exception list. Then, in step 1406, the node storing the codingblock identifies the non-excepted node in the new temperature clusterthat is to store the coding block. For example, if the data is notexcepted, then the node holding the coding block will identify itscorresponding node in the new temperature cluster; however, if the datais excepted, than the node will consult the original parity pattern andidentify the node that the data would have been stored on without theexception, and identify the node corresponding to the original paritypattern in the new temperature cluster. Finally, in step 1408, the nodestoring the coding block transmits the coding block to the identifiednode in the new temperature cluster.

Each node in the cluster will maintain a copy of the exception table,which will need to be referenced when data is accessed. Accordingly, fora fully robust system, the following information would be required tolocate a particular stored block.

A) The parity pattern (i.e., whether parity nodes are stored onlogically adjacent nodes, whether they are separated by one, etc.);

B) The coding line offset;

C) The IDA offset;

D) The parity rotation constant;

E) The number of data and parity nodes; and

F) The exception table.

It should be noted that the DBMS must reject new data stores if morenodes become accessible than there are parity nodes for a particularsystem. Accordingly, if a particular data store is configured for fivedata nodes and two parity peers, the data store will not be able toaccept more data if more than two nodes become inaccessible.

Another important function of the disclosed DBMS is to collect andaggregate certain information that is related to runtime statistics,utilization and operation of the DBMS. For example, a non-exhaustivelist of tracked statistics would be percent of storage utilized, amountof data read in a last time unit (such as 1 second), the amount of datawritten in a last time unit (again, 1 second would be typical), thetotal data rate (data read plus data written) in a last time unit (suchas 1 second), number of input transactions (reads) in a last time unit(such as 1 second), number of output transactions (writes) in a lasttime unit (such as 1 second), and the total transaction count (readsplus writes) in a last time unit (such as 1 second). While statisticssuch as these are tracked on a per node basis, the goal of the disclosedsystem is to aggregate the required data, including the calculation ofany higher order quantities, across a fixed grouping of nodes only onetime so that there are no duplicates or wasted processor resources. Suchfixed groupings of nodes include, but are not limited to, individualclusters of nodes, or sets of nodes storing data for a particulardatabase table.

Accordingly, the designated leader of a particular group of nodes(cluster) is assigned the task of performing data collection andaggregation (including calculation of higher order values) for aparticular cluster or table. In particular, the designated leader isresponsible for assigning a node or nodes to aggregate data from aparticular group of other nodes. If an assigned node goes down, thedesignated leader is responsible for designating a replacement.

Turning to FIG. 15 , the process by which a new aggregation node isassigned is illustrated. There are two events that may cause a newaggregation node to be assigned; first, on system startup, aggregationnodes may be assigned, and second, when the designated leader losescontact with an aggregation node for longer than a predetermined timeperiod, such as, for example, 30 seconds or one minute. One of thoseevents is noted by the designated leader in step 1502. Then, in step1504, the designated leader reviews the available nodes, and in step1506, the designated leader selects one of the available nodes.

In certain cases, more than one node may be assigned to aggregate datafor a particular cluster or table. For example, for a cluster with manynodes; i.e., 64, the designated leader may assign four nodes toaggregate data, each of which will collect data from fifteen other nodesand aggregate that data with its own data. FIG. 16 illustrates theprocess by which the designated leader determines how many nodes arerequired to aggregate data. In step 1602, the designated leaderdetermines the amount of data to aggregate. Then, in step 1604, thedesignated leader determines the number of nodes to assign to aggregatedata. Finally, in step 1606, nodes are assigned to aggregate data as inFIG. 15 .

The foregoing description of the disclosure has been presented forpurposes of illustration and description, and is not intended to beexhaustive or to limit the disclosure to the precise form disclosed. Thedescription was selected to best explain the principles of the presentteachings and practical application of these principles to enable othersskilled in the art to best utilize the disclosure in various embodimentsand various modifications as are suited to the particular usecontemplated. It is intended that the scope of the disclosure not belimited by the specification, but be defined by the claims set forthbelow. In addition, although narrow claims may be presented below, itshould be recognized that the scope of this invention is much broaderthan presented by the claim(s). It is intended that broader claims willbe submitted in one or more applications that claim the benefit ofpriority from this application. Insofar as the description above and theaccompanying drawings disclose additional subject matter that is notwithin the scope of the claim or claims below, the additional inventionsare not dedicated to the public and the right to file one or moreapplications to claim such additional inventions is reserved.

What is claimed is:
 1. A database management system comprising: a codingcluster for storing data, wherein the coding cluster includes aplurality of nodes, wherein each node of the plurality of nodesincludes: a server having a network interface; and a switch coupled tothe network interface, wherein the switch allows each node tocommunicate with other nodes of the plurality of nodes; wherein, inresponse to an election event, a majority of the plurality of nodesselect via a consensus protocol, one of the plurality of nodes as adesignated leader node and wherein the plurality of nodes includes atleast two other nodes; and wherein the designated leader node performsoperations that include maintaining a collection of coding linesassociated with the plurality of nodes, the collection of coding linesincluding an inventory of open coding lines of the collection of codinglines having at least one open coding block and wherein the maintainingthe collection of coding lines maintains at least one open coding linefor each node of the plurality of nodes.
 2. The database managementsystem of claim 1, wherein the consensus protocol includes nodes of theplurality of nodes randomly voting for any node of the plurality ofnodes.
 3. The database management system of claim 1, wherein thedesignated leader node maintains at least one open coding line for eachnode of the plurality of nodes by creating a new open coding line to addto the collection of coding lines when the inventory of the open codinglines for a node is empty.
 4. The database management system of claim 1,wherein the election event includes the majority of the plurality ofnodes losing contact with a prior designated leader node.
 5. Thedatabase management system of claim 1, wherein the election eventincludes a verified failure of a prior designated leader node.
 6. Thedatabase management system of claim 1, wherein the election eventincludes a system startup.
 7. The database management system of claim 1,wherein the operations further include: assigning one of the at leasttwo other nodes to be an aggregation node that collects and aggregatesperformance data associated with the plurality of nodes.
 8. The databasemanagement system of claim 7, wherein the performance data for a node ofthe plurality of nodes includes a percentage of storage utilized.
 9. Thedatabase management system of claim 7, wherein the performance data fora node of the plurality of nodes includes an amount of data read in atime period.
 10. The database management system of claim 7, wherein theperformance data for a node of the plurality of nodes includes a totaldata rate in a time period.
 11. The database management system of claim7, wherein the performance data for a node of the plurality of nodesincludes an amount of input transactions in a time period.
 12. Thedatabase management system of claim 7, wherein the performance data fora node of the plurality of nodes includes an amount of outputtransactions in a time period.
 13. The database management system ofclaim 7, wherein the performance data for a node of the plurality ofnodes includes an amount of total transactions in a time period.
 14. Amethod comprising: providing a coding cluster for storing data, whereinthe coding cluster includes a plurality of nodes, wherein each node ofthe plurality of nodes includes: a server having a network interface;and a switch coupled to the network interface, wherein the switch allowseach node to communicate with other nodes of the plurality of nodes;wherein the plurality of nodes include a designated leader node and atleast two other nodes; maintaining, via the designated leader node, acollection of coding lines associated with the plurality of nodes, thecollection of coding lines including an inventory of open coding linesof the collection of coding lines having at least one open coding blockand wherein the maintaining the collection of coding lines maintains atleast one open coding line for each node of the plurality of nodes; andfacilitating, in response to an election event, replacing the designatedleader node with a new designated leader node, wherein a majority of theplurality of nodes select, via a consensus protocol, the new designatedleader node to replace the designated leader node.
 15. The method ofclaim 14, wherein the consensus protocol includes nodes of the pluralityof nodes randomly voting for any node of the plurality of nodes.
 16. Themethod of claim 14, wherein the designated leader node maintains atleast one open coding line for each node of the plurality of nodes bycreating a new open coding line to add to the collection of coding lineswhen the inventory of the open coding lines for a node is empty.
 17. Themethod of claim 14, wherein the election event includes the majority ofthe plurality of nodes losing contact with the designated leader node.18. The method of claim 14, wherein the election event includes averified failure of the designated leader node.
 19. The method of claim14, wherein the election event includes a system startup.
 20. The methodof claim 14, further comprising: assigning, via the designated leadernode, one of the at least two other nodes to be an aggregation node thatcollects and aggregates performance data associated with the pluralityof nodes.